The MIDI (Musical Instrument Data Interface) standard has become almost universally accepted as a method of communicating music performance data. MIDI was designed primarily for communication between discrete components such as keyboards and synthesizers. However, MIDI is now used quite extensively to generate music in personal computers. Although the availability of such an accepted standard is very beneficial, there are some drawbacks to using the MIDI standard in computers.
MIDI represents music as a series of discrete events. One of the most basic examples involves playing a single note. In the MIDI standard, a note is played by sending a "note-on" event to a synthesizer or other rendering device and then sending a "note-off" event. The synthesizer starts playing the note immediately upon receiving the note-on event, and continues playing the note until receiving the note-off event. This makes sense when the music events are being generated by a keyboard, because each event corresponds to an actual, physical event taking place at the keyboard: the note-on event corresponds to pressing a key, and the note-off event corresponds to releasing the key. It makes sense for the keyboard to send a notification when an event occurs, and for the synthesizer to respond whenever it receives the notification.
When music is generated by a computer, however, low-level events are not typically generated in response to physical events. When a computer generates a note, it is more convenient to specify the note and its duration. This reduces the work of whatever high-level program is generating music; the program can send a note once to a synthesizer, rather than the two times that would be required to send a note-on notification and a subsequent note-off notification.
Another reason for specifying notes by duration is to avoid confusion that might otherwise result when a synthesizer simultaneously renders different incoming MIDI streams. Each stream can have note-on and note-off commands concerning the same notes. This can produce especially difficult problems when it is desired to prematurely halt the music from one of the streams. If the command stream is simply discontinued, some notes will be left "stuck" on, since the appropriate note-off commands are never sent.
In some computer-based systems, note commands are send ahead of time to a rendering component. The rendering component places future note commands from the different streams in a common time queue, for playback at designated times. When halting a stream, it is necessary not only to interrupt the command stream itself, but to flush the time queue. However, simply removing all of the note commands that originated from a particular stream might have the undesirable effect of leaving a note stuck on, because the note-off event for that note might be removed from the queue after its corresponding note-on has been played.
One solution to this problem of stuck notes has been to simply command "all notes off" when terminating a particular stream. Another, less drastic solution has been to immediately play any note-off commands that are currently in a queue, and then removing the commands from the queue. However, either of these approaches might interfere with notes generated by other streams. A more complex (but more effective) approach is to maintain a table indicating the status of each note. For each "on" note, the table indicates the stream responsible for turning the note on. When a stream is terminated, the table can be examined to determine which notes need to be turned off. Although this method is workable, it is somewhat awkward and inefficient.
Similar problems occur with incremental MIDI commands that represent a series of small, incremental control movements. For example, such incremental commands can be generated in response to a pitch-bend controller on a MIDI keyboard. The controller is a wheel that can be turned by the user to gradually "bend" (change the pitch of) current notes. The wheel typically has a spring-return to a neutral position. Rotating the wheel results in a series of MIDI events, each corresponding to a small incremental rotation of the wheel. In this physical environment, the wheel eventually returns to its neutral position, thus terminating the "bend" and returning the pitch to its original value. Controllers such as this can be used to vary other real-time parameters such as volume.
Computer programs can use incremental MIDI commands to create desired music effects. However, dynamically halting a MIDI stream in the middle of such an effect can leave the pitch permanently "bent," thereby ruining the performance.
U.S. Pat. No. 5,827,989, issued to Microsoft Corporation on Oct. 27, 1998, entitled "A System and Method For Representing a Musical Event and For Converting the Musical Event Into a Series of Discrete Events," described an invention that alleviated some problems in dealing with continuous events such as pitch bends. In accordance with that patent, a set of incremental musical events such as a series of pitch bend events is represented by a single "curve" event containing parameters defining a continuous event.
Representing on/off events and continuous events as single events rather than discrete time-spaced events has certain advantages in terms of precision and bandwidth. However, many computer synthesizers still require input in the form of conventional, time-spaced, MIDI events. Thus, it is eventually necessary to convert different event representations into MIDI format, and to produce a single stream of timed MIDI commands for submission to a single computer synthesizer. When dealing with multiple input streams, this creates the problems noted above when trying to dynamically halt a particular stream before it has concluded.